Build the catalog image from a clean checkout - #5157

catalog/Dockerfile assumed pre-built assets — COPY build — with npm run build run outside Docker in the deploy workflow. So docker build catalog/ failed on a fresh clone, and the shipped artifact depended on whatever node/npm the CI runner resolved rather than on the Dockerfile. Catalog was the only image in the repo built this way.

The build now happens in a node stage inside the Dockerfile. The context moves from catalog/ to the repo root, because the webpack build resolves modules from shared/ (internals/webpack/webpack.base.js resolve.modules, and tsconfig.json paths) — app code imports schemas/*.json from there.

deploy-catalog.yaml drops its setup-node/npm ci/npm run build steps and is restructured into a single build job plus a per-registry push matrix. The build job runs on pull requests too, as a build-only check: previously the image build was exercised only on master push, so Dockerfile breakage surfaced after merge, and there was no way to rehearse a change to it. Because it is one job definition, the PR check and the master build can't drift apart. Both events share one buildx GHA cache scope (master builds warm the cache PRs read; the reverse is blocked by GitHub's cache isolation), which replaces the setup-node npm cache that an in-Docker build can't use.

On master, the build job hands the image to the push jobs as a short-lived workflow artifact (docker load-able tarball, 1-day retention), so each registry receives byte-for-byte the image that was built, and each push is an independent matrix job.

Marketplace can't be re-pushed under the same tag, which previously forced an implicit ordering — MP pushed last — to keep the job re-runnable. The matrix dissolves that constraint: a failed target is retried alone via "Re-run failed jobs", downloading the same image artifact, without replaying pushes that already succeeded.

Verification

• Builds from a clean checkout with no catalog/node_modules and no catalog/build present.
• The 718 static assets are byte-identical (SHA-256) to an out-of-Docker npm ci && npm run build of the same source at the same node/npm. The image additionally contains the two pre-existing config.js/config.json symlinks.
• Image is unchanged in size (394 MB) and matches the previous one layer-for-layer.
• Container serves / and /config.js with envsubst substitution applied, as before.
• After a source-content change, npm ci stays cached and only the copy + webpack layers rebuild.

Measured on this PR's own runs: 3m28s cold with no cache to read (webpack 67s, cache export 86s), and 22s when the build context is unchanged — but that second figure is the floor, not a steady state. It needs the workflow file to be the only change, since every committed file under the catalog/** and shared/** trigger paths is also in the build context.

The dominant path — app source changed, dependencies unchanged — measures 1m53s: npm ci served from cache, ~18s importing cached layers, 2.7s re-copying the context, webpack 68s, cache export 6.3s. Roughly a third of runs will be closer to cold, because 12 of the last 25 catalog commits also touched catalog/package-lock.json, which invalidates the npm ci layer.

The previous pipeline's last five master runs took 2m31s-2m51s including the three registry pushes, so it isn't directly comparable to a build-only job. The narrower comparison: both pipelines re-run webpack on any catalog change, and both cache dependency installation (setup-node cached the npm download, buildx now caches the whole npm ci layer). What's genuinely added is the cache export: 86s on a cold full export, but only 6.3s on the dominant path and 1.3s when nothing changed. So on the common case the tax is single-digit seconds against a 68s webpack step that both pipelines pay.

The master-only artifact hand-off (tarball export + upload in build, download + docker load in each push job) is new overhead that PR runs don't exercise — its real cost shows up in the first master runs after merge.

Notes

• No catalog/CHANGELOG.md entry: this has no runtime or user-facing effect, and every existing entry there is a product change. Happy to add one if you'd rather.
• The ignore file is catalog/Dockerfile.dockerignore (BuildKit's per-Dockerfile ignore) so no other image's build context is affected, and it is an allow-list — a new top-level directory stays out of the context by default. catalog/.dockerignore no longer applied once the context moved, so it's removed.
• node:26-trixie-slim is digest-pinned, matching the lambda Dockerfiles' convention. Debian rather than alpine because esbuild and msgpackr-extract ship glibc prebuilds.